Product development projects typically require significant effort to monitor and manage. Furthermore, computer software development projects are inherently difficult to manage. This difficulty is partly due to the large number of tasks and associated deliverables that comprise a software package and the vastness of paperwork and project files associated with these tasks and deliverables. Another contributing factor involves the complex set of interdependencies established between individual tasks and deliverables during the development cycle of a software package. Yet another contributing factor is the need to generate and maintain a design specification associated with the software being developed.
Management of development projects typically includes organizing, maintaining, and controlling access to project documents, schedules, and the like. Furthermore, there are often multiple development projects occurring concurrently within an enterprise organization, thus significantly expanding the document management efforts. Historically, management of a master project schedule entails, among other tasks, manually entering data into a scheduling application, manually creating links between schedules, and manually aggregating individual developers' task schedules into the master project schedule. These are cumbersome and error-prone tasks, with little to no oversight and quality control.
A master project schedule is often in a state of flux, whereby management solicits the developers for task statuses and related schedule updates. Often, the feedback provided to management by the developers has little oversight and is not according to a rigid policy, procedure, or verification process. Thus, the actual status of a project schedule is often difficult to ascertain since the progress of individual tasks are dictated by subjective, and often self-supporting, progress reports by those individuals that are assigned to the task.
Public and private networks provide a useful and simple communication mechanism for members of a project team to obtain all the information related to a project. Maintaining web pages associated with the schedules of a project and of project members allows members of a project team to easily access the schedule to determine the status of the project. However, the tasks involved with creating and updating schedules for individual members of a project team and the tasks involved with consolidating all the schedules of individual members into a single project schedule are not trivial.
One approach to project schedule management involves creating all the schedules manually using an HTML editor. The project manager could create the overall project schedule showing the major project tasks. The project tasks could be divided into subtasks and the subtasks could be informally assigned to members of a project team. Then, each member of a project team could create a member schedule, with a risk of no uniformity in the format of the individual member schedules. From all the members' schedules, the project manager could aggregate all the subtasks schedules associated with the project schedule and update the overall project schedule. Furthermore, all schedules could maintain a history of all the schedules of the tasks. With a small group, scheduling is tedious. With a large group, scheduling is complicated as well as tedious, especially the aggregation of all the subtask schedules with the project task schedules.
Another approach to project schedule management involves automating interdependent processes via a network-based project schedule management system. For example, a procedural computer programming language could be used to develop a network-based project schedule management system. With such an automated system, global functions could perform all the tasks of the project schedule management system. However, modifying or correcting features of the system could pose challenges, such as with locating where in the program changes need to be made. Furthermore, changes in one part of the system could affect another part of the system which, if not implemented correctly, could break the system's functionality. Still further, separate code might need to be developed for similar system components and functionality, such as for multiple editor pages, where implementation of global changes to the system or addition of components to the system could require changes to each of the separate code modules or development of new code.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.